Reiterate layout step until section addresses converge #688

parth-07 · 2026-01-05T16:27:32Z

This commit modifies the layout step to reiterate until the section addresses converge. The reiteration has an upper limit of 4. On reaching this limit, a warning is emitted and the layout reiteration is stopped.

Please note that this reiteration limit is for layout iterations before relaxations take place. After a layout relaxation pass, the reiteration count is reset to 0.

Resolves #687

quic-seaswara

Why are you exposing maxPreRelaxationPasses to the function ?

I feel createProgramHeaders is becoming overly iterative.

The logic can be contained in GNULDBackend.

parth-07 · 2026-01-14T05:36:32Z

Why are you exposing maxPreRelaxationPasses to the function ?

We need to use maxPreRelaxationPasses in createProgramHdrsandcreateScriptProgramHdrs` function to determine
the number of times the layout needs to be computed when it is not getting converged.

I feel createProgramHeaders is becoming overly iterative.
The logic can be contained in GNULDBackend.

To push the logic in GNULDBackend, we will need to refactor createProgramHdrs and createScriptProgramHdrs so that
we can run the inner loop of these functions directly from GNULDBackend. However, in our offline discussions, you told not
to refactor those functions as of now as that will increase the testing requirement.

quic-areg · 2026-01-13T23:55:24Z

lib/Target/CreateScriptProgramHeaders.hpp

-  while (out != outEnd) {
-    bool useSetLMA = false;
+  int preRelaxPassIter = 0;
+  do {


This is a massive loop that requires indenting everything and makes the diff really large. I wonder if this can be avoided somehow? Can we isolate the single-pass into a new function and then have a small loop in relax() or somewhere else?

Can we isolate the single-pass into a new function and then have a small loop in relax() or somewhere else?

That will also result in a huge diff, same as it is right now.

I wonder if this can be avoided somehow?

We can keep the indentation of the original loop as before, but still enclose it within do .. while(), however, then the indentation would be incorrect and reading the code in future might be misleading in the future due to incorrect indentation.

I was thinking to first refactor the single-pass in a separate patch, and then this PR just becomes adding a loop

If refactoring is not an option, can the loop be a while() loop instead of a do...while? Since the function is massive it's not obvious what condition we are looping over until we find the end of the loop many lines down.

Regardless of whatever decision is taken here I think the two .hpp files could benefit from refactoring somewhere down the line.

lib/Target/GNULDBackend.cpp

quic-areg · 2026-01-14T17:01:18Z

include/eld/Target/GNULDBackend.h

  GNUVerDefFragment *GNUVerDefFrag = nullptr;
  std::unordered_map<const ResolveInfo *, uint16_t> OutputVersionIDs;
 #endif
+  OutputSectionEntry * changedOutputSection = nullptr;


Layout iterations only continue when section addresses change, but what about symbol-only forward references?

cat > 1.c << \! int foo() {return 0;} ! cat > cycle.t << \! SECTIONS { . = 0x1000; .text : {*(.text*)} a = b + 4; b = a + 4; } ! cat > sym.t << \! PHDRS {TEXT PT_LOAD;} SECTIONS { . = 0x1000; .text : {*(.text*)} : TEXT a = b + 4; b = c + 4; c = 0x2000; } ! clang -c 1.c ld.eld 1.o -T sym.t # a,b,c = 0x8, 0x2004, 0x2000 ld.lld 1.o -T sym.t # a,b,c = 0x2008, 0x2004, 0x2000 ld.lld 1.o -T cycle.t # error: assignment to symbol a does not converge ld.eld 1.o -T cycle.t # a = 0x14; b=0x18

Layout iterations only continue when section addresses change, but what about symbol-only forward references?

I plan to handle symbol address convergence in the next patch. The subsequent patches will add support for symbol address convergence, improved diagnostics related to layout iterations and convergence, and some heuristics to reduce the number of iterations wherever possible.

This commit modifies the layout step to reiterate until the section addresses converge. The reiteration has an upper limit of 4. On reaching this limit, a note is emitted and the layout reiteration is stopped. It is not warning as of now because it can cause link failure when --fatal-warnings is used. This note will later be converted to a warning once the feature is complete. Please note that this reiteration limit is for layout iterations before relaxations take place. After a layout relaxation pass, the reiteration count is reset to 0. Resolves qualcomm#687 Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>

quic-areg · 2026-01-14T17:28:30Z

lib/Target/CreateScriptProgramHeaders.hpp

  };
-
+  bool linkerScriptHasMemoryCommand = m_Module.getScript().hasMemoryCommand();
  auto reset_state = [&](OutputSectionEntry *OS = nullptr) {


we reuse the segment table across passes; segments from a transient layout can stick around:

In the first pass we create a new PT_LOAD for .bar due to the forward reference that remains even after v is fixed:

cat > 1.c << \! [[gnu::section(".foo")]] int foo = 1; [[gnu::section(".bar")]] int bar = 2; ! cat > fwd.t << \! SECTIONS { . = u; .foo : {*(.foo)} . = v; .bar : {*(.bar)} u = 0x1000; v = u + 0x10; } ! cat > nofwd.t << \! SECTIONS { . = 0x1000; .foo : {*(.foo)} . = 0x1010; .bar : {*(.bar)} } ! clang -c 1.c ld.eld 1.o -T fwd.t -o fwd # two PT_LOADs with .foo and .bar separate. ld.eld 1.o -T nofwd.t -o nofwd # single PT_LOAD with .foo and .bar together. ld.lld 1.o -T fwd.t -o fwd ld.lld 1.o -T fwd.t -o nofwd llvm-readelf -l fwd nofwd

quic-areg · 2026-01-14T17:36:22Z

include/eld/Target/GNULDBackend.h

 #endif
+  OutputSectionEntry * changedOutputSection = nullptr;
+  const int maxPreRelaxationPasses = 4;
 };


It looks like lld's max passes is 5. Is there any reason we picked a different number?

quic-areg · 2026-01-14T17:39:13Z

include/eld/Diagnostics/DiagLayouts.inc

 DIAG(warn_empty_segment, DiagnosticEngine::Warning,
-     "Empty segment: '%0'")
+     "Empty segment: '%0'")
+DIAG(note_section_address_not_converging, DiagnosticEngine::Note,


should this be a warning instead?

quic-areg · 2026-01-14T17:40:38Z

lib/Target/CreateScriptProgramHeaders.hpp

-      hasError = true;
-    }
+      setVMA(*cur, vma, /*ignoreChangedSection=*/false);
+      cur->setAddr(vma);


do we need both setVMA and cur->setAddr()?

parth-07 force-pushed the SectionAddressConvergence branch 5 times, most recently from 81a1a0b to 7b61c10 Compare January 7, 2026 09:58

partaror requested review from quic-areg and quic-seaswara January 7, 2026 09:59

parth-07 force-pushed the SectionAddressConvergence branch from 7b61c10 to 2d6821f Compare January 8, 2026 12:30

partaror force-pushed the SectionAddressConvergence branch from 2d6821f to 93a16f2 Compare January 9, 2026 10:30

quic-seaswara requested changes Jan 13, 2026

View reviewed changes

parth-07 force-pushed the SectionAddressConvergence branch from 93a16f2 to 42473f8 Compare January 14, 2026 05:47

parth-07 requested a review from quic-seaswara January 14, 2026 05:48

parth-07 force-pushed the SectionAddressConvergence branch from 42473f8 to 485a38d Compare January 14, 2026 06:24

quic-areg reviewed Jan 14, 2026

View reviewed changes

parth-07 force-pushed the SectionAddressConvergence branch from 485a38d to 27b20eb Compare January 14, 2026 17:31

parth-07 requested a review from quic-areg January 14, 2026 17:32

quic-areg reviewed Jan 14, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Reiterate layout step until section addresses converge #688

Reiterate layout step until section addresses converge #688

parth-07 commented Jan 5, 2026

Uh oh!

quic-seaswara left a comment

Uh oh!

parth-07 commented Jan 14, 2026

Uh oh!

quic-areg Jan 13, 2026

Uh oh!

parth-07 Jan 14, 2026

Uh oh!

quic-areg Jan 14, 2026 •

edited

Loading

Uh oh!

Uh oh!

quic-areg Jan 14, 2026

Uh oh!

parth-07 Jan 14, 2026

Uh oh!

quic-areg Jan 14, 2026

Uh oh!

quic-areg Jan 14, 2026

Uh oh!

quic-areg Jan 14, 2026

Uh oh!

quic-areg Jan 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Reiterate layout step until section addresses converge #688

Are you sure you want to change the base?

Reiterate layout step until section addresses converge #688

Conversation

parth-07 commented Jan 5, 2026

Uh oh!

quic-seaswara left a comment

Choose a reason for hiding this comment

Uh oh!

parth-07 commented Jan 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

quic-areg Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

quic-areg Jan 14, 2026 •

edited

Loading